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Outline 


•  Analysis  integration  problem 

•  Analysis  contracts  approach 

-  Specification 

-  Verification 

•  Experimental  results 


Model  integration  in  CPS 


Aerodynamics 


•  Subtle  mismatches  between  technical  domains 

•  Lead  to  costly  fixes  or  failures 


Analytic  aspect  of  integration 


Analysis 


/ 

Bin  packing 

1 

Analysis 


System 


•  Frequency  scaling  is  applicable  only  when: 

-  used  after  Bin  packing 

-  the  system  is  behaviorally  deadline-monotonic 

•  Otherwise,  frequency  scaling  may  render  the  system  not  schedulable 

•  Hence,  model  consistency  is  not  sufficient 


Analysis  integration  problem 


Analysis 


Analysis 


_  _  _  _  I  Domain  2 

•  Out-of-order  execution 

•  Invalidation  of  assumptions 


Existing  solutions 


•  Assume-guarantee  component  composition  does  not  handle 
analytic  integration  of  tools  [1][2]. 

•  Architectural  views  tackle  model  consistency,  not  analytic 
tool  consistency  [3][4] 

•  Meta-level  AADL  languages  do  not  allow  domain-specific 
semantics  [5] 

•  Previous  work  on  contracts:  single  domain  only,  unsound  and 
incomplete  verification  [6] 

[1]  Frehse  et  al.  Assume-guarantee  reasoning  for  hybrid  l/O-automata  by  over-approximation  of 

continuous  interaction,  2004 

[2]  Sangiovanni-Vincentelli  et  al.  Taming  Dr.  Frankenstein:  contract-based  design  for  cyber-physical 

systems,  2013 

[3]  Torngren  et  al.  Integrating  viewpoints  in  the  development  of  mechatronic  products,  2013 

[4]  Rajhans  et  al.  Supporting  heterogeneity  in  cyber-physical  systems  architectures,  2014 

[5]  Boddy  et  al.  The  FUSED  meta-language  and  tools  for  complex  system  engineering,  2011 

[6]  Nam  et  al.  Resource  allocation  contracts  for  open  analytic  runtime  models,  2011  7 
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Outline 


•  Analysis  integration  problem 

•  Analysis  contracts  approach 

-  Specification 

-  Verification 

•  Experimental  results 


Analysis  contracts  approach 


•  Formalize  analysis  domains 

•  Specify  dependencies  and  assumptions  of  analyses 

•  Determine  correct  ordering  of  analyses 

•  Verify  assumptions  of  analyses 
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Outline 


•  Analysis  integration  problem 

•  Analysis  contracts  approach 

-  Specification 

-  Verification 

•  Experimental  results 
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Running  example 


Scheduling 


Battery 


Battery  Scheduling 

Discharge  Charge 

44 


System 


L 


12 


Verification  domain 


Scheduling  domain  ct  .  . 

sched 


Battery  domain  <7batt 


System 
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Verification  domain 

•  Domain  ct  is  a  many-sorted  signature  {St,  S,  ^  %  Ow): 

-  st  set  of  sorts  -  system  elements  and  standard 
sorts 

•  E.g.:  : B ,  Z,  Threads,  Batteries,  SchedPol 

-  S'.  Skx  ...  x  SLk~  static  functions  that  encode 
design  properties 

•  E.g.:  Period,  Dline,  CPU  Bind,  Voltage 

-  SL^  x  ...  x  Sl^  -  runtime  functions  that  encode 
dynamic  properties 

•  E.g.:  CanPrmpt:  Threads  x  Threads  ->  ¥> 

TN\  Batteries  xZ->Z 
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Verification  domain 


•  Domain  ct  is  a  many-sorted  signature  (A,  S,  %  Oa): 

-  T:  execution  semantics  -  set  of  sequences  of  5^ 
assignments 

•  E.g.:  thread  scheduler  state  model  for  asched 

battery  state  model  for  for  crbatt 

-  Ow:  domain  interpretation  for  A  and  s 

•  E.g.:  iSchedPol}a  =  {RMS,  DMS,  EDF} 

•  Architectural  model  m  is  an  interpretation  {[  ]>m  of  A,  S, 
and  <T 

-  E.g.:  iThreads}m  =  {  SensorSample,  Ctrl1(  Ctrl2 } 

^CPUBind][m  =  {  (Ctrl,,  CPU,),  ( Ctrl2 ,  CPU2),  ...  } 

-  OauOm  is  a  full  interpretation 


Analysis  contract 


•  Given  a  domain  a,  analysis  contract  C  is  a  tuple  (I,  O,  A,  G) 

-  Inputs  I  £  &  u  s 

-  Outputs  O  Q  St  U  S 

-  Assumptions  A  £  <fa 

-  Guarantees  G  £  <jya 

•  Where: 

-  5<j"=  {V|3}  v^.v^ip  |  {V|3}  V!..vn*<p  :  ip 

-  <p  is  a  static  logical  formula  over  St  and  S 

-  qi  is  an  LTL  formula  over  St,  s,  and  Hi 

•  semantics  is  given  in  a  standard  way 

-  :  means  =>  in  case  of  V,  and  a  in  case  of  3 


Outline 


•  Analysis  integration  problem 

•  Analysis  contracts  approach 

-  Specification 

-  Verification 

•  Experimental  results 
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Contract  I/O  dependencies 

Scheduling 


Frequency  scaling  assumption 


Behavioral  equivalence  to  deadline-monotonic  scheduling 
•  V  t1(  t2:  Threads  •  tx  ^  t2  a  CPL/B/nd(t1)  =  CPUBind(t2)  : 

G  (CanPrmpt(tv  t2)  =>  D//ne(t1)  <  DHne{ t2)) 


EDF  =  DMS 


P=D 


P=D,  Harmonic,  Sync 


P=D 
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Assumption  verification 


•  SMT  solver  finds  solutions  for  static  fragment  <p 

-  V  t1(  t2.Threads  |  tx  ^  t2  a  CPUBind( =  CPUBind(t2) 

•  Model  checking  property  ip  in  a  behavioral  Promela 
model  for  each  SMT  solution: 

-  G  ( CanPrmpt{ t1#  t2)  =>  D//'ne(t1)  <  Dline( t2)) 
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Battery  modeling 

Battery 


•  Restrictions  on  acceptable  thermal  configurations 

•  Guarantee:  unacceptable  ones  don't  occur 


.  •  Abstraction:  geometry 

•  Simulates  heat  propagation 
I  •  Cannot  scale  to  dynamic  scheduling: 

I  simulates  only  fixed  cell  configurations 


•  Abstraction:  circuits 

•  Selects  a  scheduler  for  cell  connections 

•  Oblivious  of  heat:  treats  any  configuration 
acceptable  heat-wise 


Battery  scheduling  guarantee 


•  "Bad"  thermal  configurations  not  reachable 


QOOO 


OQQQ 


OOOQ 


QOOO 


QOOO 


QOOO 


OOOQ 


OOOO 


•  TA/(b,  i)  E  $i-  number  of  cells  in  b  with  i  thermal 
neighbors 

•  K( b,  i)  €  S  -  experimental  coefficient  for  TN[b,  i) 

•  Guarantee: 

V  b:  Batteries  •  G  ( I  l=0..3K(bf  \)*TN{b,  i)  )  >  0 


Battery  modeling 

Battery 


Selects  a  battery  scheduler 

Guarantee:  V  b:  Batteries  •  G  (  £  i=0  3K( b,  i)*77V(b,  i)  )  >  0 
Verified  with  battery  Promela/Spin  model 


Determines  K(b,  i)  via  simulation 
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Outline 


•  Analysis  integration  problem 

•  Analysis  contracts  approach 

-  Specification 

-  Verification 

•  Experimental  results 
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Framework  implementation 
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Scalability  evaluation 


•  SMT  solving  typically  takes  less  than  0.1  second 

•  Spin  model  checking  times: 


a 


sched  ' 


a 


batt  ' 


Threads 

(R/D)MS 

EDF  time  I 

Cells 

FGURR 

FGWRR 

GPWRR 

time 

_  1 

time 

time 

time 

3 

0.01 

0.01 

9 

0.13 

0.15 

0.15 

4 

0.01 

0.52 

12 

0.61 

2.34 

3.94 

5 

0.07 

33.4 

16 

44 

31.4 

127 

6 

0.37 

2290.0 

20 

1060 

619 

Out  Mem 

7 

2.18 

Out  Mem 

25 

Out  Mem 

Out  Mem 

Out  Mem 

8 

12.4 

Out  Mem 

9 

71.2 

Out  Mem 

All  times  are  in  seconds 

10 

421 

Out  Mem 

26 

11 

Out  Mem 

Out  Mem 

Summary 


•  Analysis  integration  is  error-prone 

-  Incorrect  ordering 

-  Violation  of  implicit  assumptions 

•  Our  solution: 

-  Contract  specification  language 

-  Contract  verification  algorithm 

•  Effective,  extensible,  and  scalable 

•  Future  work: 

-  Assumptions  behind  <T  implementation 

-  Analysis  contracts  for  multiple  views 
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Contracts 


Security  Analysis 

•  Ansec.C:I  =  { T,ThSecCl},0  =  {NotColoc},A  =  0,  G  =  {5} 

—  g:  V  t1(t2  •  ThSecCl (tj)  =£  ThSecClfa)  =>  G  NotColoc(t2') 

Multiprocessor  scheduling:  (Binpacking  +  scheduling) 

•  Ansched.C:l  =  [T,C,  NotColoc,  Per.WCET,  Dline},0  =  {CPU Bind),  A  =  0,  G  =  {T7} 

—  g:  V  tx,t:2  •  ti  G  NotColoc (t2)  =>  CPUBind(t1')  =£  CPUBind(t2 ) 

Frequency  Scaling 

•  Anfreqsc.C:l  =  {T,C,  CPU  Bind,  Dline},0  =  { CPUFreq),G  =  0,  A  =  {a} 

—  a:  Vt1(t2  •  CPUBinditi)  =  CPUBindit^-.G^CanPrmptitx.t-^  =>  Dline(t1')  Dline(t2~) 

Model  checking  periodic  program  (REK): 

•  ArVefe.C:/  =  {T,  C,Per,Dline,WCET,CPUBind},0  =  {ThSafe},G  =  0,A  =  {al7  a2} 

•  a^Vt  •  Per(t)  =  Dline(t),  a2:Vt1,t2  ■  G^Canprmpt^t^t^  =>  G  -1  CanPrmpt(t2,t1)') 

Thermal  runaway: 

•  Antherm.C:  I  =  [B,  BatRows.BatCols,  Voltage),  0  =  {/C},A  =  0,  G  =  0 

Battery  Scheduling 

•  Anbsched.C:  I  =  [B,  BatRows.BatCols}, 0  =  {BatConnSchedPol,HasReqLifetime,SeriqlReq,ParalRea},A  =  0,  G 
{5} 

•  5-:  G(tf(0)  X  TiV(O)  +  AT(1)  X  TiV(l)  +  AT(2)  X  7W(2)  +  AT(3)  X  TN( 3)  >  0) 


